Microvisor-based malware detection appliance architecture

ABSTRACT

A threat-aware microvisor may be deployed in a malware detection appliance architecture and execute on a malware detection system (MDS) appliance to provide exploit and malware detection within a network environment. The microvisor may underlie an operating system kernel of the MDS appliance and execute in kernel space of the architecture to control access to kernel resources of the appliance for any operating system process. A type 0 virtual machine monitor may be disposed over the microvisor and execute in user space of the architecture as a pass-through module configured to expose the kernel resources of the appliance to the operating system kernel. One or more hypervisors, e.g., type 1 VMM, may be further disposed over the microvisor and execute in user space of the architecture under control of the microvisor to support execution of one or more guest operating systems inside one or more full virtual machines.

RELATED APPLICATION

The present application is a divisional of U.S. patent application Ser.No. 14/962,497 filed Dec. 8, 2015, now U.S. Pat. No. 9,934,376 issuedApr. 3, 2018, which claims priority from commonly owned ProvisionalPatent Application No. 62/097,499, entitled Microvisor-Based MalwareDetection Appliance Architecture, filed on Dec. 29, 2014, the contentsof which are incorporated herein by reference.

BACKGROUND Technical Field

The present disclosure relates to malware detection and, morespecifically, to a microvisor-based malware detection architecture.

Background Information

A virtual machine monitor (VMM) or hypervisor may be a hardware orsoftware entity configured to create and run a software implementationof a computing platform or machine, i.e., a virtual machine. Thehypervisor may be implemented as a type 1 VMM executing over nativehardware of the computing platform, or a type 2 VMM executing within anoperating system environment of the platform. The hypervisor may befurther deployed in a virtualization system that fully simulates(virtualizes) physical (hardware) resources of the computing platform.Such a full virtualization system may support execution of a pluralityof operating system instances inside a plurality of virtual machines,wherein the operating system instances share the hardware resources ofthe platform. The hypervisor of the full virtualization system maymanage such sharing by hiding the hardware resources of the computingplatform from users (e.g., application programs) executing on eachoperating system instance and, instead, providing an abstract, virtualcomputing platform.

A prior implementation of a virtualization system includes a specialvirtual machine and a hypervisor that creates other virtual machines,each of which executes an independent instance of an operating system.Malicious code may be prevented from compromising resources of thesystem through the use of policy enforcement and containment analysisthat isolates execution of the code within a virtual machine to block orinhibit its execution within the system (i.e., outside of the virtualmachine). The policy enforcement and containment may be directed toactive (often computationally intensive) analysis of operating systemdata streams (typically operating system version and patch specific) todetect anomalous behavior. However, malicious code may attempt to evadedetection by avoiding malicious behavior when executing in a virtualmachine or the malicious code may attempt to exploit a vulnerability ofthe virtual machine itself. Therefore, such data stream analysis may beof limited use with respect to detection of malware that exploitsvulnerabilities in processes or applications (or the virtual machine)executing on systems within a network environment. Accordingly, there isa need for an enhanced exploit and malware detection system that detectsanomalous behavior of malware (e.g., exploits and other malicious codethreats) and collects analytical information relating to such behavior.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and further advantages of the embodiments herein may be betterunderstood by referring to the following description in conjunction withthe accompanying drawings in which like reference numerals indicateidentically or functionally similar elements, of which:

FIG. 1 is a block diagram of a network environment that may beadvantageously used with one or more embodiments described herein;

FIG. 2 is a block diagram of a node that may be advantageously used withone or more embodiments described herein;

FIG. 3 is a block diagram of the threat-aware microvisor that may beadvantageously used with one or more embodiments described herein;

FIG. 4 is a block diagram of a malware detection appliance architecturethat may be advantageously used with one or more embodiments describedherein;

FIG. 5 is an example procedure for deploying the threat-aware microvisorin a malware detection appliance architecture; and

FIG. 6 is a block diagram of an exemplary virtualization architectureincluding a trusted computing base that may be configured to provide atrusted malware detection environment in accordance with one or moreembodiments described herein.

OVERVIEW

The embodiments described herein provide a threat-aware microvisordeployed in a malware detection appliance architecture and executing ona malware detection system (MDS) appliance to provide exploit andmalware detection within a network environment. The microvisor mayunderlie an operating system kernel of the MDS appliance and execute inkernel space of the architecture to control access to kernel resourcesof the appliance for any operating system process. A type 0 virtualmachine monitor (VMM 0) may be disposed over the microvisor and operatein user space of the architecture as a pass-through module configured toexpose the kernel resources of the appliance to the operating systemkernel. One or more hypervisors, e.g., type 1 VMM (VMM 1), may befurther disposed over the microvisor and operate in user space of thearchitecture under control of the microvisor to support execution of oneor more guest operating systems inside one or more full virtual machines(VMs).

Exploit and malware detection on the MDS appliance may be performed inaccordance with one or more software modules or engines configured todetect suspicious and/or malicious behaviors of an operating systemprocess when, e.g., executing an object, and to correlate and classifythe detected behaviors as indicative of malware. Detection of asuspicious and/or malicious object may be performed in accordance with asequential two-phase approach, e.g., static analysis followed by dynamicanalysis, of the object. Static analysis may perform examination of theobject to determine whether it is suspicious and, if so, the suspiciousobject may be subjected to dynamic analysis, which may instrument thebehavior of the object as it runs in a guest operating system. Abehavioral analysis logic engine (BALE) and a classifier may thereaftercooperate to perform correlation and classification of the detectedbehaviors.

In an embodiment, the static analysis phase may include a staticanalysis engine having a heuristics engine executing as one or more usermode processes of the operating system kernel. The heuristics engine mayrun one or more heuristics to provide (heuristic) analysis using, e.g.,rules or weighting methods to determine whether the object issuspicious. In response to a suspicious determination (or, in someembodiments, even during static analysis itself), the static analysisengine may analyze the object to, inter alia, identify software profileinformation associated with the guest operating system for execution ina VM, e.g., VM 1. The static analysis engine may then provide thesoftware profile information to another user mode process embodied as ascheduler, which may coordinate with VMM 1 to spawn and schedule the VM1 to analyze the object in accordance with the dynamic analysis phase.Dynamic analysis may include exploit and malware detection performed bythe microvisor, VMM 1 and VM 1 to detect behaviors of the object.Illustratively, VMM 1 may configure VM 1 with a software profile thatreplicates a run-time environment that the object expects and, in someembodiments, a run-time environment of a real destination device. Thebehaviors of the object may be detected by instrumenting (i.e.,monitoring) the object using, e.g., instrumentation logic, as the objectexecutes in the guest operating system at VM 1, wherein the monitoredrun-time behaviors may be captured as dynamic analysis results by themicrovisor and VMM 1.

The dynamic analysis results may be provided to the BALE, which mayprovide correlation information to the classifier. The BALE may beembodied as a rules-based correlation engine illustratively executing asan isolated process disposed over the microvisor. The BALE may beconfigured to operate on correlation rules that define, among otherthings, patterns (such as, e.g., sequences) of known malicious behaviorsthat may collectively correlate to malicious events (activity) and, insome embodiments, also patterns of known benign behaviors that maycollectively correlate to benign (non-malicious) events. The dynamicanalysis may collect the monitored behaviors and cooperate with the BALEto examine those behaviors, separately or collectively, as patterns todetermine whether they represent malicious or benign events indicativeof the presence of malware. For example, a behavior may be detected thatappears benign, but when examined with other behaviors, may beindicative of malicious activity.

In an embodiment, the rules of the BALE may be correlated against thedynamic analysis results to generate correlation information pertainingto, e.g., a level of risk or a numerical score used to arrive at adecision of maliciousness. The classifier may be embodied as aclassification engine executing as a user mode process of the operatingsystem kernel and configured to use the correlation information providedby BALE to render a decision as to whether the object is malicious.Illustratively, the classifier may be configured to classify thecorrelation information, including monitored behaviors (expected andunexpected/anomalous) and capability violations, of the object relativeto those of known malware and benign content.

In some embodiments, the MDS may be configured to perform only dynamicanalysis, whose results may be provided to the BALE, which may providecorrelation information to the classifier. Accordingly, in suchembodiments, the initial static analysis of the objects as describedherein may be avoided or significantly reduced (for example, to onlyidentify suitable software profiles to process the objects). Forexample, suspicious or malicious objects (or simply “selected” objects)may be provided directly for dynamic analysis, as might be the casewhere additional forensic behavioral analyses of the suspicious ormalicious objects are desired.

In an embodiment, the microvisor may be stored in a memory of the MDSappliance as a module of a trusted computing base (TCB) that alsoincludes a root task module configured to cooperate with the microvisorto load one or more other modules executing on the MDS appliance. Inaddition, one or more of the malware detection system engines (modules)may be included in the TCB to provide a trusted malware detectionenvironment. Illustratively, it may be desirable to organize modulesassociated with a decision of malware to be part of the TCB. Forexample, the BALE and/or classifier may be included in the TCB for theMDS appliance.

DESCRIPTION

FIG. 1 is a block diagram of a network environment 100 that may beadvantageously used with one or more embodiments described herein. Thenetwork environment 100 illustratively includes a plurality of computernetworks organized as a public network 120, such as the Internet, and aprivate network 130, such an organization or enterprise (e.g., customer)network. The networks 120, 130 illustratively include a plurality ofnetwork links and segments connected to a plurality of nodes 200. Thenetwork links and segments may include local area networks (LANs) 110and wide area networks (WANs) 150, including wireless networks,interconnected by intermediate nodes 200 _(I) to form an internetwork ofnodes, wherein the intermediate nodes 200 _(I) may include networkswitches, routers and/or one or more malware detection system (MDS)appliances (intermediate node 200 _(M)). As used herein, an appliancemay be embodied as any type of general-purpose or special-purposecomputer, including a dedicated computing device, adapted to implement avariety of software architectures relating to exploit and malwaredetection functionality. The term “appliance” should therefore be takenbroadly to include such arrangements, in addition to any systems orsubsystems configured to perform a management function for exploit andmalware detection, and associated with other equipment or systems, suchas a network computing device interconnecting the WANs and LANs. TheLANs 110 may, in turn, interconnect end nodes 200 _(E) which, in thecase of private network 130, may be illustratively embodied asendpoints.

In an embodiment, the endpoints may illustratively include, e.g.,client/server desktop computers, laptop/notebook computers, processcontrollers, medical devices, data acquisition devices, mobile devices,such as smartphones and tablet computers, and/or any other intelligent,general-purpose or special-purpose electronic device having networkconnectivity and, particularly for some embodiments, that may beconfigured to implement a virtualization system. The nodes 200illustratively communicate by exchanging packets or messages (i.e.,network traffic) according to a predefined set of protocols, such as theTransmission Control Protocol/Internet Protocol (TCP/IP); however, itshould be noted that other protocols, such as the HyperText TransferProtocol Secure (HTTPS), may be advantageously used with the embodimentsherein. In the case of private network 130, the intermediate node 200_(I) may include a firewall or other network device configured to limitor block certain network traffic in an attempt to protect the endpointsfrom unauthorized users. Unfortunately, such conventional attempts oftenfail to protect the endpoints, which may be compromised.

FIG. 2 is a block diagram of a node 200, e.g., MDS appliance node 200_(M), that may be advantageously used with one or more embodimentsdescribed herein. The node 200 illustratively includes one or morecentral processing unit (CPUs) 212, a memory 220, one or more networkinterfaces 214 and one or more devices 216 connected by a systeminterconnect 218, such as a bus. The devices 216 may include variousinput/output (I/O) or peripheral devices, such as storage devices, e.g.,disks. The disks may be solid state drives (SSDs) embodied as flashstorage devices or other non-volatile, solid-state electronic devices(e.g., drives based on storage class memory components), although, in anembodiment, the disks may also be hard disk drives (HDDs). Each networkinterface 214 may include one or more network ports containing themechanical, electrical and/or signaling circuitry needed to connect thenode to the network 130 to thereby facilitate communication over thenetwork. To that end, the network interface 214 may be configured totransmit and/or receive messages using a variety of communicationprotocols including, inter alia, TCP/IP and HTTPS.

In one or more embodiments where the MDS appliance 200 _(M) iscommunicatively coupled with the network 130, the network interface 214may operate as a data capturing device (sometimes referred to as a “tap”or “network tap”) that is configured to receive incoming network (data)traffic propagating from public network 120 and into private network130, and provide at least some of this data traffic or a duplicated copyof the traffic for malware detection. In one embodiment, the MDSappliance may be positioned (deployed) behind the firewall at an ingresspoint into the private network 130, and at least partially in-line withnetwork devices (e.g., endpoints) so as to subject the incoming trafficto analysis (e.g., through static analysis) and potentially block thattraffic which is classified as malware from reaching its destination(e.g., the endpoints). In another embodiment, the static analysis may beat least partially performed by the firewall or other intermediatedevice, or performed by the network interface 214 (e.g., by CPU 212and/or a digital signal processor on a network interface card).

The memory 220 may include a plurality of locations that are addressableby the CPU(s) 212 and the network interface(s) 214 for storing softwareprogram code (including application programs) and data structuresassociated with the embodiments described herein. The CPU 212 mayinclude processing elements or logic adapted to execute the softwareprogram code, such as threat-aware microvisor 300 and modules of malwaredetection appliance architecture 400, and manipulate the datastructures. Exemplary CPUs may include families of instruction setarchitectures based on the x86 CPU from Intel Corporation of SantaClara, Calif. and the x64 CPU from Advanced Micro Devices of Sunnyvale,Calif.

An operating system kernel 230, portions of which are typically residentin memory 220 and executed by the CPU, functionally organizes the nodeby, inter alia, invoking operations in support of the software programcode and application programs executing on the node. A suitableoperating system kernel 230 may include the Windows® series of operatingsystems from Microsoft Corp of Redmond, Wash., the MAC OS® and IOS®series of operating systems from Apple Inc. of Cupertino, Calif., theLinux operating system and versions of the Android™ operating systemfrom Google, Inc. of Mountain View, Calif., among others. Suitableapplication programs may include Adobe Reader® from Adobe Systems Inc.of San Jose, Calif. and Microsoft Word from Microsoft Corp of Redmond,Wash. Illustratively, the software program code may be implemented asuser mode processes 240 of the kernel 230. As used herein, a process(e.g., a user mode process) is an instance of software program code(e.g., an application program) executing in the operating system thatmay be separated (decomposed) into one or more threads, wherein eachthread is a sequence of execution within the process.

It will be apparent to those skilled in the art that other types ofprocessing elements and memory, including various computer-readablemedia, may be used to store and execute program instructions pertainingto the embodiments described herein. Also, while the embodiments hereinare described in terms of software program code, processes, andcomputer, e.g., application, programs stored in memory, alternativeembodiments also include the code, processes and programs being embodiedas engines and/or modules consisting of hardware, software, firmware, orcombinations thereof.

I. Threat-Aware Microvisor

FIG. 3 is a block diagram of the threat-aware microvisor 300 that may beadvantageously used with one or more embodiments described herein. Thethreat-aware microvisor (hereinafter “microvisor”) may be configured tofacilitate run-time security analysis, including exploit and malwaredetection and threat intelligence, of operating system processesexecuting on the node 200. To that end, the microvisor may be embodiedas a light-weight module disposed or layered beneath (underlying, i.e.,directly on native hardware) the operating system kernel 230 of the nodeto thereby virtualize the hardware and control privileges (i.e., accesscontrol permissions) to kernel (e.g., hardware) resources of the node200 that are typically controlled by the operating system kernel.Illustratively, the kernel resources may include (physical) CPU(s) 212,memory 220, network interface(s) 214, and devices 216. The microvisor300 may be configured to control access to one or more of the resourcesin response to a request by an operating system process to access theresource.

As a light-weight module, the microvisor 300 may provide avirtualization layer having less functionality than a typicalhypervisor. Therefore, as used herein, the microvisor 300 is a module(component) that underlies the operating system kernel 230 and includesthe functionality of a micro-kernel (e.g., protection domains, executioncontexts, capabilities and scheduling), as well as a subset of thefunctionality of a hypervisor (e.g., hyper-calls to implement a virtualmachine monitor). Accordingly, the microvisor may cooperate with aunique virtual machine monitor (VMM), i.e., a type 0 VMM, to provideadditional virtualization functionality in an operationally and resourceefficient manner. Unlike a type 1 or type 2 VMM (hypervisor), the type 0VMM (VMM 0) does not fully virtualize the kernel (hardware) resources ofthe node and supports execution of only one entire operatingsystem/instance inside one virtual machine, i.e., VM 0. VMM 0 may thusinstantiate VM 0 as a container for the operating system kernel 230 andits kernel resources. In an embodiment, VMM 0 may instantiate VM 0 as amodule having instrumentation logic 360 directed to determination of anexploit or malware in any suspicious operating system process (kernel oruser mode).

As used herein, an exploit may be construed as information (e.g.,executable code, data, one or more commands provided by a user orattacker) that attempts to take advantage of a computer program orsystem vulnerability, often employing or constituting malware.Typically, a vulnerability may be a coding error or artifact of acomputer program that allows an attacker to alter legitimate controlflow during processing of the computer program by an electronic deviceand, thus, causes the electronic device to experience undesirable orunexpected behaviors. The undesired or unexpected behaviors may includea communication-based or execution-based anomaly which, for example,could (1) alter the functionality of the electronic device executingapplication software in a malicious manner; (2) alter the functionalityof the electronic device executing the application software without anymalicious intent; and/or (3) provide unwanted functionality which may begenerally acceptable in another context. To illustrate, a computerprogram may be considered a state machine where all valid states (andtransitions between states) are managed and defined by the program, inwhich case an exploit may be viewed as seeking to alter one or more ofthe states (or transitions) from those defined by the program. Malwaremay be construed as computer code that is executed to harm or co-optoperation of an electronic device or misappropriate, modify or deletedata. Conventionally, malware may often be designed with maliciousintent, and may be used to facilitate an exploit. For convenience, theterm “malware” may be used herein to describe a malicious attack, andencompass both malicious code and exploits detectable in accordance withthe disclosure herein.

Illustratively, VMM 0 is a pass-through module configured to expose thekernel resources of the node (as controlled by microvisor 300) to theoperating system kernel 230. VMM 0 may also expose resources such asvirtual CPUs (threads), wherein there is one-to-one mapping between thenumber of physical CPUs and the number of virtual CPUs that VMM 0exposes to the operating system kernel 230. To that end, VMM 0 mayenable communication between the operating system kernel (i.e., VM 0)and the microvisor over privileged interfaces 315 and 310. The VMM 0 mayinclude software program code (e.g., executable machine code) in theform of instrumentation logic 350 (including decision logic) configuredto analyze one or more interception points originated by one or moreoperating system processes to invoke the services, e.g., accesses to thekernel resources, of the operating system kernel 230. As used herein, aninterception point is a point in an instruction stream where controlpasses to (e.g., is intercepted by) either the microvisor, VMM 0 oranother virtual machine. A system call provides an interception point atwhich a switch in privilege levels occurs in the operating system, i.e.,from a privilege level of the user mode process to a privilege level ofthe operating system kernel. VMM 0 may intercept the system call andexamine a state of the process issuing (sending) the call to determinewhether the call is suspicious. Illustratively, VMM 0 may containcomputer executable instructions executed by the CPU 212 to performoperations that initialize and implement the instrumentation logic 350,as well as operations that spawn, configure, and control/implement VM 0and its instrumentation logic 360. Example threat-aware microvisor andVMM 0 are described in U.S. patent application Ser. No. 14/229,580titled Exploit Detection System with Threat-Aware Microvisor by Ismaelet al., filed Mar. 28, 2014, which application is hereby incorporated byreference.

In an embodiment, the microvisor 300 may be organized to include aprotection domain illustratively bound to VM 0. As used herein, aprotection domain is a container for various data structures, such asexecution contexts, scheduling contexts, and capabilities associatedwith the kernel resources accessible by an operating system process.Illustratively, the protection domain may function at a granularity ofan operating system process (e.g., a user mode process 240) and, thus,is a representation of the process. Accordingly, the microvisor mayprovide a protection domain for the process and its run-time threadsexecuting in the operating system. A main protection domain (PD 0) ofthe microvisor controls all of the kernel resources available to theoperating system kernel 230 (and, hence, the user mode process 240) ofVM 0 via VMM 0 and, to that end, may be associated with the servicesprovided to the user mode process by the kernel 230.

An execution context 320 is illustratively a representation of a thread(associated with an operating system process) and, to that end, definesa state of the thread for execution on CPU 212. In an embodiment, theexecution context may include inter alia (i) contents of CPU registers,(ii) pointers/values on a stack, (iii) a program counter, and/or (iv)allocation of memory via, e.g., memory pages. The execution context 320is thus a static view of the state of thread and, therefore, itsassociated process. Accordingly, the thread executes within theprotection domain associated with the operating system process of whichthe thread is a part. For the thread to execute on a CPU 212 (e.g., as avirtual CPU), its execution context 320 is tightly linked to ascheduling context 330, which may be configured to provide informationfor scheduling the execution context 320 for execution on the CPU 212.Illustratively, the scheduling context information may include apriority and a quantum time for execution of its linked executioncontext on CPU 212.

In an embodiment, the capabilities 340 may be organized as a set ofaccess control permissions to the kernel resources to which the threadmay request access. Each time the execution context 320 of a threadrequests access to a kernel resource, the capabilities 340 are examined.There is illustratively one set of capabilities 340 for each protectiondomain, such that access to kernel resources by each execution context320 (i.e., each thread of an execution context) of a protection domainmay be defined by the set of capabilities 340. For example, physicaladdresses of pages of memory 220 (resulting from mappings of virtualaddresses to physical addresses) may have associated access permissions(e.g., read, write, read-write) within the protection domain. To enablean execution context 320 to access a kernel resource, such as a memorypage, the physical address of the page may have an associated capability340 (access permission) that defines how the execution context 320 mayreference that page. Illustratively, the capabilities may be examined byhardware (e.g., a hardware page fault upon a memory access violation) orby program code. A violation of a capability in a protection domain maybe an interception point, which returns control to the VM (e.g., VM 0)bound to the protection domain.

Assume a user mode process 240 has one or more threads that run on oneor more CPUs 212. Each thread has an associated execution context 320that defines its state. When executing on a CPU 212, the thread mayattempt to access a resource (a memory page). VMM 0 may instruct themicrovisor 300 to configure the access permission to the memory pageaccording to a definition of the capability within the protection domainbound to the process executing the thread. Assume further that thecapability specifies that a protection domain (e.g., PD 0) can have onlyread-only access to the memory page. If the CPU 212 attempts to write tothat memory, i.e., a write access, a trap (e.g., an exception, such as apage fault or general protection fault) may be generated by the CPU andthe microvisor 300 may report the trap (via an exception handler) to VMM0. VMM 0 may decide that such write access should be allowed andinstructs the microvisor to allow the access. Alternatively, VMM 0 maydecide that such write access warrants further analysis using adifferent set of capabilities to further monitor the process 240.

In an embodiment, the different set of capabilities may pertain tocertain kernel resources, such as memory regions (as opposed to memorypages of the regions). Here, the capabilities may not be configured todefine access permissions at the granularity of memory pages (e.g., 4Kbytes) because of the substantial memory resources (i.e., page tableentries) needed to accommodate sufficient pages to cover large memoryregions. As such, in an embodiment, a region of memory (i.e., having aplurality of memory pages) may be associated with certain permissions(read-only, write-only) as defined by the capabilities, wherein thememory region may be “fine-grained” (e.g., enlarged or shrunk) to enableread or write only permissions to memory pages within the region.Accordingly, the capabilities may provide one or more variablegranularity memory regions for each protection domain, wherein a leastgranularity is a memory page (e.g., 4 Kbytes).

In an embodiment, the microvisor 300 may be configured to performscheduling of execution contexts 320 and verification of operationalrequests by the execution contexts with respect to capabilities 340. Ifthere is a violation of the capabilities for a protection domain, a trap(e.g., an exception, such as a page fault or general protection fault)may be generated by the CPU (or other hardware) and serviced by anexception handler of the microvisor. For example, if a process 240attempts to access a resource to which the capability specifies it doesnot have permission, the CPU may generate the trap and the exceptionhandler may report the violation to, e.g., VMM 0 for analysis. Inaddition, the microvisor may provide VMM 0 with state informationassociated with the execution context 320 executing at the time of thetrap. The capability violation may trigger invocation of theinstrumentation logic 350 of VMM 0 to determine whether the process issuspicious or even an exploit and, if so, an appropriate course ofaction. Depending on the seriousness of the violation (e.g., a degree ofsuspicion of an exploit), VMM 0 may decide to, e.g., change a registervalue or issue a capability change. VMM 0 may then provide instructionsto the microvisor (PD 0) as to a course of action.

For instance, assume the capability violation arises from an attempt bythe process 240 to execute program instructions on a memory page notpermitted to execute such instructions (e.g., a page table entryassociated with the memory page configured with a no-execute bit). As aresult, a page fault exception may occur that triggers invocation of theinstrumentation logic 350, which may apply heuristics to determinewhether the memory page likely contains an exploit as opposed to benignprogram instructions, e.g., just-in-time (JIT) compiler programinstructions. That is, the instrumentation logic may apply theheuristics to rule out (eliminate) the likelihood that the capabilityviolation (i.e., page fault exception) is caused by benign programinstructions. Illustratively, the heuristics perform static analysis ofthe memory page to determine whether the capability violation isconsistent with JIT compiler generated program instructions. To thatend, the heuristics may determine whether the memory page is allocatedby the process 240 and whether the contents of the memory page containwell-known program instruction sequences and headers, e.g., industrystandard prefix and postfix generated instruction sequences and vendoridentifying headers. In contrast, exploits (i.e., malware) may containnon-standard program instruction sequences and unusual headers. As aresult, the heuristics may determine that a threshold of confidence(i.e., suspicion of an exploit) is exceeded when it is statisticallylikely the memory page contains an exploit.

In another instance, the instrumentation logic 350 may apply theheuristics to detect a sequence of capability violations that indicatesthe presence of an exploit (or malware). Assume a first capabilityviolation arises from an attempt by the process 240 to write programinstructions on a memory (code) page without write permission (e.g., apage table entry associated with the memory page configured with aread-only bit or no write bit and an execute bit). Assume also that asecond capability violation arises from an attempt by the process toexecute those program instructions on the code page. In response to thefirst capability violation, a first page fault exception occurs thattriggers invocation of the instrumentation logic 350, which may applyheuristics that note (i.e., record) the attempted write to the codepage. In response to the second capability violation, a second pagefault exception may occur that again triggers invocation of theinstrumentation logic, which applies the heuristics that recall theattempt to write instructions to the code page (i.e., a same memory pagethat led to the first page fault exception) in response to the firstcapability violation. Accordingly, the heuristics may determine that anattempt to “execute after write” (i.e., an attempt to execute programinstructions from a memory page that was previously written) hasoccurred, which may indicate a likelihood of presence of an exploit (ormalware). That is, the instrumentation logic may apply the heuristics todetect an execute-after-write arising from two or more capabilityviolations that indicates the likelihood of presence of an exploit (ormalware), e.g., the threshold of confidence is exceeded. As such, apattern (e.g., sequence) of capability violations may be used todetermine whether the threshold of confidence (i.e., suspicion of anexploit) is exceeded indicating the statistical likelihood that theprocess contains an exploit (or malware).

II. Malware Detection Appliance Architecture

In one or more embodiments, the MDS appliance node (MDS) 200 _(M) may beembodied as an intermediate node configured to analyze network trafficassociated with one or more endpoints 200 _(E) of a computer network,such as private network 130. The MDS 200 _(M) may be illustrativelypositioned (e.g., as an ingress/egress point) within the private network130 to intercept (i.e., snoop) the traffic. The intercepted traffic maybe replayed (i.e., transmitted) to or its contents otherwise submittedto and, in any case, instrumented (i.e., monitored) at the MDS 200 _(M).

Illustratively, the MDS appliance 200 _(M) may include functionalitydirected to replaying of network traffic and using instrumentation ofthat traffic to monitor the processing of objects within the traffic.For every network packet received, the MDS appliance may run a heuristicto compute a flow, as appropriate, for the packet, and then create(spawn) a virtual machine (VM) to emulate the endpoint using an image ofan operating system (guest operating system and, often, one or moreapplications) configured to replicate a software processing environmentof the endpoint, e.g., based on a payload (object) of the packet to bereplayed and instrumented. An object may include a logical entity suchas, for example, a web page, an email or email attachment, an executable(i.e., binary or script), a file (which may contain an executable), oruniversal resource locator (URL). Information as to an appropriateprocessing environment may be provided by the packet itself, e.g., thepacket header may identify the packet type, for example, a document suchas a Portable Document Format (PDF) document and, thus, the processingenvironment may include a document reader, such as a PDF reader fromAdobe Systems Inc. Additionally, or in alternative embodiments,information may also be provided by the endpoint (such as thedestination endpoint as specified in the packet) to the MDS indicating atype of application software (process) executing within the operatingsystem on the endpoint. The MDS may then launch a copy of theapplication along with appropriate instrumentation to process eachobject. For example, assume the MDS replays HTTPS traffic received atthe endpoint which executes, inter alia, an application (i.e., a webbrowser). The MDS may capture the network (HTTPS) traffic destined tothe endpoint, spawn the VM and launch a copy of the web browser alongwith instrumentation to monitor the traffic.

In an embodiment, the threat-aware microvisor 300 may be deployed in avirtualization architecture as a module of a virtualization systemexecuting on the MDS 200 _(M) to provide exploit and malware detectionwithin the network environment 100. FIG. 4 is a block diagram of amalware detection appliance architecture 400 that may be advantageouslyused with one or more embodiments described herein. Illustratively, thearchitecture 400 may organize the memory 220 of the MDS appliance 200_(M) as a user space 402 and a kernel space 404. The microvisor mayunderlie the operating system kernel 230 and execute in the kernel space404 of the architecture 400 to control access to the kernel resources ofthe MDS 200 _(M) for any operating system process (kernel or user mode).Notably, the microvisor 300 executes at the highest privilege level ofthe hardware (CPU) to virtualize access to the kernel resources of theMDS appliance in a light-weight manner when, e.g., a user mode process240 requests the services of the operating system kernel 230.

The user mode processes 240 and operating system kernel 230 may executein the user space 402 of the appliance architecture 400, although itwill be understood to those skilled in the art that the user modeprocesses may execute in another address space defined by the operatingsystem kernel. Illustratively, the operating system kernel 230 mayexecute under control of the microvisor at a privilege level (i.e., alogical privilege level) lower than a highest privilege level of themicrovisor, but at a higher CPU privilege level than that of the usermode processes 240. In addition, VMM 0 and VM 0 may execute in userspace 402 of the architecture 400. As a type 0 virtual machine monitor,VMM 0 and VM 0 may execute at the highest (logical) privilege level ofthe microvisor. That is, VMM 0 and VM 0 may operate under control of themicrovisor at the highest microvisor privilege level, but may notdirectly operate at the highest CPU (hardware) privilege level.

One or more hypervisors, e.g., type 1 VMM, may be disposed as one ormore modules over the microvisor 300 and operate in user space 402 ofthe architecture 400 under control of the microvisor at the highestmicrovisor privilege level to provide additional layers ofvirtualization for the MDS 200 _(M). Illustratively, each hypervisorprovides full virtualization of kernel (hardware) resources and supportsexecution of one or more entire operating system instances (i.e., guestoperating system) inside one or more full virtual machines. To that end,a hypervisor (e.g., VMM 1) may instantiate a full VM (e.g., VM 1) as amodule provisioned with a software profile that includes a guestoperating system (e.g., guest operating system 415) and any associatedapplication programs (e.g., application 425), as well as instrumentationlogic (e.g., instrumentation logic 360A) directed to determination ofmalware in any suspicious object or application running on the guestoperating system. The software profile (e.g., guest operating systemand/or application program) provisioned and configured in the VM may bedifferent (e.g., in vendor, type and/or version) from the softwareprofile provisioned and configured in other instantiated VMs (e.g., VMN).

Illustratively, each hypervisor (e.g., VMM 1-1_(N)) may contain computerexecutable instructions executed by the CPU 212 to perform operationsthat initialize and configure the instrumentation logic (e.g.,instrumentation logic 350A-N), as well as operations that spawn,configure, and control/implement the VM (e.g., VM 1-N) and itsinstrumentation logic (e.g., 360A). In an embodiment, there isillustratively one hypervisor (e.g., VMM 1-1_(N)) for each VM (e.g., VMs1-N), wherein each VM may be used to emulate an endpoint. The MDS 200_(M) may not emulate every endpoint on, e.g., a segment, but when amalicious object (such as, e.g., a file of a network packet) isidentified, the VMM 1 of the MDS appliance may create (spawn) a full VM1 to analyze that object. The virtualization layers of the MDS 200 _(M)may cooperate to implement an abstraction of virtual devices exposed as,e.g., virtual network interfaces to the VMs.

Illustratively, the instrumentation logic 350 of VMM 0 may includemonitoring logic configured to monitor and collect behaviors detectedduring processing of a suspicious object or application, wherein thebehaviors may or may not constitute capability violations (e.g.,generated by CPU 212 in response to one or more interception points). Asystem call illustratively provides an interception point at which achange in privilege levels occurs in the operating system, i.e., from aprivilege level of the user mode process to a privilege level of theoperating system kernel. VMM 0 may intercept the system call and examinea state of the process issuing (sending) the call. The instrumentationlogic 350 of VMM 0 may analyze the system call to determine whether thecall is suspicious and, if so, cooperate with VMM 1 to instantiate(spawn) one or more virtual machines (e.g., VM 1) equipped withmonitoring functions, e.g., of instrumentation logic 360A, thatcooperate with the microvisor to detect anomalous behavior which may beused in determining malware.

Inference of malware may also be realized through sequences ofinterception points wherein, for example, a system call followed byanother system call having certain parameters may lead to an inferencethat the application (process) sending the calls is malware. Theinterception point thus provides an opportunity for VMM 0 to perform“light-weight” analysis to evaluate a state of the process in order todetect possible malware without requiring any policy enforcement. VMM 0may then cooperate with VMM 1 to spawn a full VM 1 and configure thecapabilities of its protection domain to enable deeper monitoring andanalysis (e.g., through interception points and capability violations)that, in combination with malware detection processing, enable detectionof expected (or unexpected) behaviors of the process that may beindicative of malware. Notably, the analysis may also classify theprocess as a type of exploit (e.g., a stack overflow) or as malware andmay even identify the same. As a result, the invocation ofinstrumentation and monitoring logic of VMM 0, VMM 1 and their spawnedVMs in response to interception points originated by operating systemprocesses and capability violations generated by the microvisoradvantageously enhance the virtualization system described herein toprovide an exploit and malware detection system configured for run-timesecurity analysis of the operating system processes executing on the MDS200 _(M).

In an embodiment, the privileged interfaces 310 and 315 may be embodiedas a set of defined hyper-calls, which are illustratively inter processcommunication (IPC) messages exposed (available) to VMM 0, VMM 1-1_(N)(including spawned VMs) and any other isolated software program code(module). The hyper-calls are generally originated by VMM 0 and VMM1-1_(N), directed to the microvisor 300 over privileged interface 310a-n, although VM 0 and VM 1-N may also originate one or more hyper-calls(IPC messages) directed to the microvisor over privileged interface 315a-n. However, the hyper-calls originated by VM 0 and VM 1-N may be morerestricted than those originated by VMM 0 and VMM 1-1_(N).

In an embodiment, the microvisor 300 may be organized to include aplurality of protection domains (e.g., PD 0-R) illustratively bound toVM 0, one or more VMs, and any isolated module, respectively. Forexample, the spawned VM (e.g., VM 1) is illustratively associated with(bound to) a copy of PD 0 (e.g., PD 1), wherein such binding may occurthrough memory context switching. In response to a decision to spawn theVM 1, VMM 1 may issue a hyper-call over interface 310 b to themicrovisor requesting creation of the protection domain PD 1. Uponreceiving the hyper-call, the microvisor 300 may copy (i.e., “clone”)the data structures (e.g., execution contexts, scheduling contexts andcapabilities) of PD 0 to create PD 1 for the VM 1, wherein PD 1 hasessentially the same structure as PD 0 except for the capabilitiesassociated with the kernel resources. The capabilities for PD 1 maylimit or restrict access to one or more of the kernel resources asinstructed through one or more hyper-calls from, e.g., VMM 1 and/or VM 1over interface 310 b to the microvisor. Such cloning of the PD 0 datastructures may also be performed to create other PDs, such as PD N forVM N as well as PD R for the isolated module disposed over themicrovisor. Accordingly, the microvisor 300 may contain computerexecutable instructions executed by the CPU 212 to perform operationsthat initialize, clone and configure the protection domains.

Advantageously, the microvisor 300 may be organized as separateprotection domain containers for the operating system kernel 230 (PD 0),one or more application programs/processes running in one or moreoperating system images (PD 1-N) and any isolated module (PD R) tofacilitate further monitoring and/or understanding of behaviors of aprocess/object and its threads through, inter alia, the use ofinterception points and capability violations as described herein. Suchorganization of the microvisor also enforces separation between theprotection domains to control the activity of the monitored process.Moreover, the microvisor 300 may enforce access to the kernel resourcesthrough the use of variously configured capabilities of the separateprotection domains. Unlike previous virtualization systems, separationof the protection domains to control access to kernel resources at aprocess granularity enables detection of anomalous behavior of malware.That is, in addition to enforcing access to kernel resources, themicrovisor enables analysis of the operation of a process/object withina spawned VM to detect exploits or other malicious code threats that mayconstitute malware.

III. Malware Detection

Exploit and malware detection on the appliance may be performed inaccordance with one or more processes embodied as software modules orengines containing computer executable instructions executed by the CPUto detect suspicious and/or malicious behaviors of an operating systemprocess (including an application program) when, e.g., executingcontents of an object, and to correlate and classify the detectedbehaviors as indicative of malware (i.e., a matter of probability). Itshould be noted that the MDS appliance may perform (implement) exploitand malware detection as its primary processing (i.e., majority use ofappliance resources) whereas, e.g., the endpoint may implement suchdetection as background processing (i.e., minor use of endpointresources) with data processing being implemented as its primaryprocessing (e.g., in the foreground having majority use of endpointresources).

Detection of a suspicious and/or malicious object may be performed atthe appliance in accordance with a sequential two-phase analysisapproach, e.g., static analysis followed by dynamic analysis, of theobject. As noted, an object may include a web page, email, emailattachment, an executable (i.e., binary or script), a file (which maycontain an executable or document), or a URL. Static analysis mayperform examination of the object to determine whether it is suspiciousand, if so, the suspicious object may be subjected to dynamic analysis,which may instrument the behavior of the object as it executes (runs) inguest operating system 415 to identify anomalous behavior and capabilityviolations of, e.g. operating system events. A behavioral analysis logicengine (BALE) 410 and a classifier 420 may thereafter cooperate toperform correlation and classification of the detected behaviors asmalicious or not. That is, the BALE 410 and classifier 420 may cooperateto analyze and classify detected behaviors of the object (based on theevents) as indicative of malware.

Illustratively, static analysis may be provided as a precursor todynamic analysis (i.e., a sequential two-phase approach) such that thestatic analysis phase may filter objects so that only suspect objectsare provided to the dynamic analysis phase and/or may determine theorder of processing (priority) of objects during the dynamic analysis,depending on the embodiment. In an embodiment, the static analysis phasemay include a static analysis engine 430 having a heuristics engine 440executing as one or more user mode processes of the operating systemkernel 230. The static analysis engine 430 and heuristics engine 440 mayemploy statistical analysis techniques, including the use of heuristics,to perform non-behavioral analysis in order to detect anomalouscharacteristics (i.e., suspiciousness and/or malware) without execution(i.e., monitoring run-time behavior) of the object. For example, thestatic analysis engine 430 may employ signatures (referred to as malware“indicators”) to match content (e.g., bit patterns) of the object withpatterns of known indicators of known malware in order to gatherinformation that may indicate that the object is suspicious ormalicious. The statistical analysis techniques may produce staticanalysis results that include, e.g., identification of communicationprotocol anomalies and/or suspect source addresses for packets of knownmalicious servers.

As used herein, static analysis (e.g., as performed by the staticanalysis engine 430) denotes examination or testing of content of anobject and observation of patterns within the content (e.g., bitpatterns) to generate a score based on the results. The score may be aprobability value (expressed in any of various ways such as, forexample, a numerical value or percent) or other indicator (quantitativeor qualitative) of security risk. A software program may be employed toexamine chunks of bytes within an object (file) and compare those chunkswith entries of a suspicious object database having chunks of objectsdeemed suspicious or malicious. If the chunks match, the score may begenerally indicative of suspiciousness of the object. Static analysismay further involve comparison of the object's content (e.g., bitpatterns) with a “blacklist” of suspicious malware indicator patternsbefore any behavioral analysis is performed. For example, a simpleindicator check (e.g., hash) against the hashes of the blacklist (i.e.,malware indicators of objects deemed suspicious) may reveal a match anda score may be generated (based on the content) that may be generallyindicative of suspiciousness of the object.

An object with an associated score (value) above a first threshold mayindicate a suspicious object, i.e., an object with a certain probabilityof being malicious, and above a second, higher threshold may indicatethat object should be classified as malware, i.e., an object with a highprobability of being malicious. The MDS may classify the object asmalware in response to the score, and may or may not bypass the dynamicanalysis as a result. If the MDS classifies the object as maliciousbased on a static analysis results score, this may be signaled to anetwork or security administrator for action by an appropriate alert.Additionally, the malicious object may be submitted for dynamic analysisfor acquisition of additional, forensic information.

In an embodiment, the heuristics engine 440 may be configured to applyrules and/or policies used to detect anomalous characteristics of theobject, such as one or more packets of network traffic, and to identifywhether the object is suspect and deserving of further analysis orwhether it is non-suspect (i.e., benign) and not in need of furtheranalysis. To that end, the heuristic engine 440 may run one or moreheuristics to provide (heuristic) analysis using, e.g., rules orweighting methods to determine whether the object (packet) issuspicious. In response to a suspicious determination or during staticanalysis (depending on the embodiment), the static analysis engine 430may analyze the object, e.g., an attached or embedded object (e.g., afile) of one or more packets of the suspicious traffic, to, inter alia,determine its type and identify software profile information associatedwith an operating system instance (i.e., guest operating system 415) ofa run-time environment for execution in a VM. The static analysis engine430 may then provide the software profile information to another usermode process embodied as scheduler 450, which may coordinate with VMM 1(e.g., via VMM 0) to spawn and schedule VM (e.g., VM 1) to replay thetraffic (and analyze the object) in accordance with the dynamic analysisstage.

In an embodiment, the scheduler 450 is responsible for schedulingdynamic analysis of objects following static analysis. The scheduler mayschedule the objects in accordance with an order (i.e., priority) basedon the static analysis score for the objects. Where the static analysisengine 430 determines a score above a prescribed threshold indicating ahigh probability the corresponding object is malicious, the object maybe scheduled for dynamic analysis ahead of other objects associated withlower static analysis scores even if those other objects were receivedearlier than the object in question. Where the object is determined tobe part of a flow (namely a group of related messages) that is part ofingress data traffic typically communicated between two electronicdevices during a single communication session (e.g., Transport ControlProtocol “TCP” session), the scheduler 450 may schedule the dynamicanalysis after receipt (i.e., buffering) of the entire flow.

In one or more embodiments, the static analysis engine 430 may beconfigured to analyze content of the packet (e.g., source and/ordestination address of a network header) to determine its source and/ordestination (i.e., web site and/or endpoint). The static analysis engine430 may then cooperate with another module, e.g., endpoint (EP) logic460, executing as a user mode process of the operating system kernel 230and configured to communicate with a corresponding endpoint 200 _(E). Inan embodiment, the MDS appliance may be configured to communicate withand instruct the endpoint to, e.g., perform an action and receivenotification of that action. For example, the MDS appliance maycommunicate with the endpoint to obtain the latest software being run atthe endpoint, or to access a database of all software images maintainedon a per endpoint basis. The MDS may then configure the run-timeenvironment for dynamic analysis on instantiation of the VM with thesame operating system and at least one of the same applications, or a“nearly similar” operating system and application that is available tothe appliance, e.g., stored in the appliance. If the same operatingsystem and applications, e.g., in terms of vendor, type and version, areemployed, then malware detection may find malware (e.g., contained inthe object) including exploits that attack vulnerabilities in thesoftware.

In other embodiments, communication with a corresponding endpoint can beavoided while still practicing other aspects of the disclosure. In suchembodiments, the software profile used to configure the VM may simply bean available profile suitable to process the object. For example, wherethe object is determined to be a Microsoft WORD® document, the VM may beprovisioned with a version of that software, and where the object is anexecutable, a process (e.g., script) may be used to launch theexecutable within the virtual run-time environment.

Dynamic analysis may include exploit and malware detection performed by,e.g., the microvisor 300, VMM 1 and VM 1 to detect behaviors of theobject. Illustratively, VMM 1 may configure VM 1 with a software profilethat replicates (mimics) a proper run-time environment to process theobject and/or that the object expects, e.g., if the object content is aweb page or PDF file, the VM may be configured with a suitableapplication program 425, such as a browser or Adobe reader application,respectively. The behaviors of the object may then be detected byinstrumenting (i.e., monitoring) the object (using, e.g.,instrumentation logic 360A) as the object executes in the guestoperating system 415 at VM 1, wherein the monitored run-time behaviorsmay be captured by the microvisor 300 and VMM 1, and provided to theBALE 410 as dynamic analysis results. In an embodiment, multiple objectsmay be processed concurrently (overlapping) in the VMs, while in otherembodiments, multiple run-time environments may be concurrently orsequentially run to analyze the same object in a single or separate VMs.The VMM 1 may configure the instrumentation logic 360A to monitordifferent types of objects, such as payloads of network (web) and emailpackets, although alternatively, there could be separate web-based andemail-based MDS appliances, each of which may be deployed in generallythe same way and configured to perform detection as generally describedherein. For example, the email-based MDS appliance may be deployed inthe private network to examine and process attachments using differenttypes of heuristics. The suspicious object may be analyzed to arrive ata malware/non-malware classification based on detected anomalousbehaviors during processing of the object (e.g., capability violationscaptured by VMM 1 and VM 1).

Illustratively, monitors may be employed during the dynamic analysis tomonitor the run-time behaviors of the object and capture any resultingactivity. The monitors may be embodied as capability violationsconfigured to trace particular operating system events. For exampleduring instrumenting of the object at the VM 1, the system events maytrigger capability violations (e.g., exceptions or traps) generated bythe microvisor 300 to enable monitoring of the object's behaviors duringrun-time. In an embodiment, the monitors may be further configured todetect behaviors that appear benign, but when analyzed collectively withother behaviors, may be indicative of malware. The monitors may includebreakpoints within code of the process executing the object beingmonitored. The breakpoints may be configured to trigger capabilityviolations or other processing used to gather or monitor the run-timebehaviors. For instance, a breakpoint may be inserted into a section ofcode of the process (e.g., application 425) running in the guestoperating system 415. When the code executes, e.g., in response to theapplication 425 accessing the object, an interception point may betriggered and a capability violation generated to enable monitoring ofthe executed code. In other words, an exception may be generated on thebreakpoint and execution of the code by the application may be trackedby the microvisor 300 and VMM 1, where the exception is a capabilityviolation.

The dynamic analysis results may be stored in memory 220 (e.g., in eventlogger 475) and provided (e.g., as input via VMM 0) to the BALE 410,which may provide correlation information (e.g., as an output via VMM 0)to the classifier 420; however, in an embodiment, the BALE may beconfigured to operate on both static and dynamic analysis results togenerate correlation information for the classifier. The BALE 410 may beembodied as a rules-based correlation engine illustratively executing asan isolated process (module) disposed over the microvisor 300 within thearchitecture 400. In accordance with the malware detection appliancearchitecture 400, the BALE 410 is illustratively associated with (boundto) a copy of PD 0 (e.g., PD R). The microvisor 300 may copy (i.e.,“clone”) the data structures (e.g., execution contexts, schedulingcontexts and capabilities) of PD 0 to create PD R for the BALE 410,wherein PD R has essentially the same structure as PD 0 except for thecapabilities associated with the kernel resources. The capabilities forPD R may limit or restrict access to one or more of the kernel resourcesas requested through one or more hyper-calls from, e.g., BALE 410 overinterface 310 r to the microvisor.

In an embodiment, the BALE 410 may be configured to operate oncorrelation rules that define, among other things, patterns (such as,e.g., sequences) of known malicious behaviors (if-then statements withrespect to, e.g., attempts by a process/object to change memory in acertain way that is known to be malicious) that may collectivelycorrelate to malicious events (activity). In some embodiments, thecorrelation rules may define patterns of known benign behaviors that maycollectively correlate to benign (non-malicious) events. The dynamicanalysis may collect the monitored behaviors and cooperate with the BALEto examine those behaviors, separately or collectively, as patterns todetermine whether they represent malicious or benign events indicativeof the presence of malware. For example, a behavior may be detected thatappears benign, but when examined with other behaviors, may beindicative of malicious activity. In addition, the BALE may performcorrelation of relationships to, e.g., render a determination of aweighted degree of similarity of matched objects based on experientialknowledge. As noted, a VM may be spawned to instrument a suspect process(object) running in a guest operating system and cooperate with themicrovisor 300 and VMM 1 to generate capability violations in responseto interception points, which capability violations are provided asdynamic analysis result inputs to the BALE 410. The rules of the BALE410 may then be correlated against those dynamic analysis results togenerate correlation information pertaining to, e.g., a level of risk ora numerical score used to arrive at a decision of (deduce)maliciousness.

The classifier 420 may be embodied as a classification engine executingas a user mode process of the operating system kernel 230 and configuredto use the correlation information provided by BALE 410 to render adecision as to whether the object is malicious. Illustratively, theclassifier 420 may be configured to classify the correlationinformation, including monitored behaviors (expected andunexpected/anomalous) and capability violations, of the object relativeto those of known malware and benign content. That is, a determinationof whether the monitored behaviors represent expected or unexpected(anomalous) behaviors is rendered by correlating the monitored behaviorsagainst behaviors of known malware. Results of the static analysis mayalso be used in the correlation and classification, e.g., by beingcombined with the results of the dynamic analysis to yield a combinedscore. In an embodiment, further static analysis and/or dynamic analysismay be performed at the appliance based on the results of correlationand classification engines. For example, an analysis controller (notshown) may be configured to examine the results of the BALE andclassifier and, in response, provide the object back to the staticand/or dynamic analysis stages for further (static and/or behavioral)analysis.

Illustratively, the BALE 410 and classifier 420 may be implemented asseparate modules as described herein although, in an alternativeembodiment, the BALE 410 and classifier 420 may be implemented as asingle module disposed over (i.e., running on top of) the microvisor300. The BALE 410 may be configured to correlate observed behaviors(e.g., results of dynamic analysis) with known malware and/or benignobjects (embodied as defined rules) and generate an output (e.g., alevel of risk or a numerical score associated with an object) that isprovided to and used by the classifier 420 to render a decision ofmalware based on the risk level or score exceeding a probabilitythreshold. A reporting logic engine 470 may execute as a user modeprocess in the operating system kernel 230 that is configured togenerate an alert for transmission external to the MDS 200 _(M) (e.g.,to one or more other endpoints 200 _(E) or to a management appliance) inaccordance with “post-solution” activity.

In an embodiment, the MDS 200 _(M) may include one or more modulesexecuting as user mode process(es) in the operating system kernel 230and configured to create indicators (signatures) of detected behaviorsof a process/object as indicative of malware and organize thoseindicators as reports for distribution to the endpoints. To that end,the MDS appliance may include an indicator generator 480 configured togenerate the malware indicators for distribution to the endpoints 200_(E). Illustratively, the malware indicators may not be typical codeindicators, e.g., anti-virus (AV) signatures; rather, the malwareindicators may be embodied as one or more hashes of the objectclassified as malware, possibly including identification informationregarding its characteristics and/or behaviors detected during staticand dynamic analysis. The indicator generator 480 may be furtherconfigured to generate both malware indicators and typical AV signaturesto thereby provide a more robust set of indicators/signatures. Theseindicators may be used internally by the MDS appliance or distributedexternally as original indicator reports to the endpoints.

The original indicator reports may also be provided to an intermediatenode 2001, such as a management appliance, within the private (customer)network 130, which may be configured to perform a management functionto, e.g., distribute the reports to other appliances within the customernetwork, as well as to nodes within a malware detection services andequipment supplier network (e.g., supplier cloud infrastructure) forverification of the indicators and subsequent distribution to other MDSappliances and/or among other customer networks. Illustratively, thereports distributed by the management appliance may include the entireor portions of the original indicator reports provided by the MDSappliance, or may include new reports that are derived from the originalreports. An indicator scanner 490 may be embodied as a user mode processand configured to obviate (prevent) processing of a suspectprocess/object based on the robust set of indicators in the report. Forexample, the indicator scanner 490 may perform indicator comparisonand/or matching during static analysis while the suspect process/objectis instrumented by the VM. In response to a match, the indicator scanner490 may cooperate with the microvisor 300 to terminate execution of theprocess/object.

In one or more embodiments, the MDS appliance 200 _(M) may be equippedwith capabilities to defeat countermeasures employed by known malware,e.g., where malware may detect that it (i.e., process/object) is runningon the microvisor 300 (e.g., through exposure of environmentalsignatures that can be used to identify the microvisor). In accordancewith the malware detection appliance architecture 400, such behavior maybe used to qualify suspiciousness. For example if a suspect objectattempts to “sleep,” the microvisor 300 and VMM 1 may detect suchsleeping activity and may be able to accelerate sleeping. A sleep systemcall (which may also be provided by a library) may be issued by anobject executed by an application to request sleeping and a capabilityviolation may be triggered based on the call (interception point) todetermine, e.g., the length of time the object requests to sleep andwhether the time may be accelerated. Here, a breakpoint may be insertedinto, e.g., the object to accelerate the sleeping time, assuming thereis an appropriate heuristic enabling such acceleration. It should benoted that it may not always be desirable to accelerate sleeping becausee.g., a shortened sleeping time may, in an embodiment, severcommunication mechanisms between applications/processes. However, ifsuch sleeping is associated with a type of malware behavior,acceleration may be performed.

The object may implement measures to identify that it is running in amicrovisor environment; accordingly, the MDS 200 _(M) may implementcountermeasures to provide strong isolation of the object duringexecution. The object may then execute and manifest behaviors that arecaptured by the microvisor and VMM 1. In other words, the microvisor andVMM 1 may detect (as a suspicious fact) that the suspect object hasdetected the microvisor. The object may then be allowed to run (whilehiding the suspicious fact) and its behaviors detected. The microvisor300 and VMM 1 may record the activity, including the detected suspiciousfact, as an event with another user mode process embodied as the eventlogger 475. In addition, the event may be provided to the correlationengine (BALE 410) and classification engine (classifier 420) forpossible classification as malware.

FIG. 5 is an example procedure for deploying the threat-aware microvisorin a malware detection appliance architecture to provide exploit andmalware detection on an object as it executes in a guest operatingsystem on the appliance. The procedure 500 starts at step 502 andproceeds to step 504 where a plurality of software modules or engines,including the microvisor, as well as VMM 0, VMM 1 and VM 1, executing onthe appliance are organized to provide the malware detection appliancearchitecture. At step 506, static analysis of the object may beperformed by, e.g., a static analysis engine and a heuristics engine todetermine a suspicious object. At step 508, dynamic analysis may beperformed on the suspicious object by, e.g., the microvisor, VMM 1 andVM 1 to capture run-time behaviors of the object as dynamic analysisresults. At step 510, the dynamic analysis results may be provided to acorrelation engine (BALE) for correlation with correlation rules and, atstep 512, the correlation engine may generate correlation information.At step 514, the correlation information may be provided to a classifierto render a decision of whether the object is malware. The procedurethen ends at step 516.

IV. Trusted Computing Base (TCB)

In an embodiment, the microvisor 300 may be stored in memory as a moduleof a trusted computing base (TCB) that also includes a root task module(hereinafter “root task”) configured to cooperate with the microvisor tocreate (i.e., load) one or more other modules executing on the CPU 212of the MDS appliance 200 _(M). In addition, one or more of the malwaredetection system engines (modules) described herein may be included inthe TCB to provide a trusted malware detection environment. For example,the BALE 410 may be loaded and included as a module in the TCB for theappliance 200 _(M).

FIG. 6 is a block diagram of an exemplary virtualization architecture600 including a TCB 610 that may be configured to provide a trustedmalware detection environment in accordance with one or more embodimentsdescribed herein. The microvisor 300 may be disposed as a relativelysmall code base that underlies the operating system kernel 230 andexecutes in kernel space 604 of the architecture 600 to control accessto the kernel resources for any operating system process (kernel or usermode). As noted, the microvisor 300 executes at the highest privilegelevel of the hardware (CPU) to virtualize access to the kernel resourcesof the appliance in a light-weight manner. The root task 620 may bedisposed as a relatively small code base that overlays the microvisor300 (i.e., underlies VMM 0 and VMM 1) and executes in user space 602 ofthe architecture 600. Through cooperation (e.g., communication) with themicrovisor, the root task 620 may also initialize (i.e., initiallyconfigure) the loaded modules executing in the user space 602. Forexample, the root task 620 may initially configure and load the BALE 410as a module of the TCB 610.

In an embodiment, the root task 620 may execute at the highest(absolute) privilege level of the microvisor. Illustratively, the roottask 620 may communicate with the microvisor 300 to allocate the kernelresources to the loaded user space modules. In this context, allocationof the kernel resources may include creation of, e.g., maximalcapabilities that specify an extent to which each module (such as, e.g.,VMM 0, VMM 1 and/or BALE 410) may access its allocated resource(s). Forexample, the root task 620 may communicate with the microvisor 300through instructions to allocate memory and/or CPU resource(s) to VMM 0,VMM 1 and BALE 410, and to create capabilities that specify maximalpermissions allocated to VMM 0, VMM 1 and BALE 410 when attempting toaccess (use) the resource(s). Such instructions may be provided over aprivileged interface embodied as one or more hyper-calls. Notably, theroot task 620 is the only (software or hardware) entity that caninstruct the microvisor with respect to initial configuration of suchresources.

In an embodiment, the root task 620 may be implemented as a “non-longlived” process that terminates after creation and initial configurationof the user space processes (modules). The non-long lived nature of theroot task is depicted by dash lining of the root task 620 in FIG. 6.Illustratively, the root task 620 is the first user space process toboot (appear) during power-up and initialization of the appliance,including loading and initial configuration of the user space modulesand their associated capabilities; the root task then terminates(disappears). The root task 620 may thereafter be re-instantiated(reappear) during a reboot process, which may be invoked in response toan administrative task, e.g., update of VMM 0. Notably, the root task620 may only appear and operate on the appliance in response to a(re)boot process, thereby enhancing security of the TCB 610 byrestricting the ability to (re)initialize the microvisor 300 afterdeployment on the MDS appliance 200 _(M).

As a trusted module of the TCB, the microvisor 300 is illustrativelyconfigured to enforce a security policy of the TCB that, e.g., prevents(obviates) alteration or corruption of a state related to security ofthe microvisor by a module (e.g., software entity) of or external to anenvironment in which the microvisor 300 operates, i.e., the TCB 610. Forexample, an exemplary security policy may provide, “modules of the TCBshall be immutable,” which may be implemented as a security property ofthe microvisor, an example of which is no module of the TCB modifies astate related to security of the microvisor without authorization. In anembodiment, the security policy of the TCB 610 may be implemented by aplurality of security properties of the microvisor 300. That is, theexemplary security policy may be also implemented (i.e., enforced) byanother security property of the microvisor, another example of which isno module external to the TCB modifies a state related to security ofthe microvisor without authorization. As such, one or more securityproperties of the microvisor may operate concurrently to enforce thesecurity policy of the TCB. An example trusted threat-aware microvisoris described in U.S. patent application Ser. No. 14/602,023 titledTrusted Threat-Aware Microvisor by Ismael et al., having a priority dateof Jul. 1, 2014.

Illustratively, the microvisor 300 may manifest (i.e., demonstrate) thesecurity property in a manner that enforces the security policy.Accordingly, verification of the microvisor to demonstrate the securityproperty necessarily enforces the security policy, i.e., the microvisor300 may be trusted by demonstrating the security property. Trusted (ortrustedness) may therefore denote a predetermined level of confidencethat the microvisor demonstrates the security property (i.e., thesecurity property is a property of the microvisor). It should be notedthat trustedness may be extended to other security properties of themicrovisor, as appropriate. Furthermore, trustedness may denote apredetermined level of confidence that is appropriate for a particularuse or deployment of the microvisor 300 (and TCB 610). The predeterminedlevel of confidence, in turn, is based on an assurance (i.e., grounds)that the microvisor demonstrates the security property. Therefore,manifestation denotes a demonstrated implementation that assurance isprovided regarding the implementation based on an evaluation assurancelevel, i.e., the more extensive the evaluation, the greater theassurance level. Evaluation assurance levels for security are well-knownand described in Common Criteria for Information Technology SecurityEvaluation Part 3: Security Assurance Components, September 2012, Ver.3.1 (CCMB-2012-09-003).

While there have been shown and described illustrative embodiments fordeploying the threat-aware microvisor in a malware detection appliancearchitecture executing on an appliance to provide exploit and malwaredetection within a network environment, it is to be understood thatvarious other adaptations and modifications may be made within thespirit and scope of the embodiments herein. For example, embodimentshave been shown and described herein with relation to providing atrusted malware detection environment having a TCB 610 that includes theBALE 410 as well as the microvisor 300 and root task 620. However, theembodiments in their broader sense are not so limited, and may, in fact,allow organization of other modules associated with a decision ofmalware to be part of the TCB. For example, the BALE 410 and classifier420 may be loaded and included as modules in the TCB 610 for the MDSappliance 200 _(M) to provide the trusted malware detection environment.Moreover, if the software code associated with the BALE and/orclassifier is too large and complex to verify as trusted, those modulesmay still be configured and disposed to run over the microvisor forisolation purposes, i.e., to isolate any malware in the module(s) bypreventing access (via hyper calls) to other module(s) of the malwaredetection environment.

In addition, embodiments have been shown and described herein withrelation to dynamic analysis of one or more operating system processesor objects using various instantiations of instrumentation logic 350,350A-N, 360, 360A. For example, instrumentation logic 350 may beincluded in VMM 0 to examine a state of a process issuing aninterception point (such as a system call) to determine whether theinterception point is suspicious, whereas instrumentation logic 360A maybe included in VM 1 to instrument (monitor) an object to detect itsbehaviors as the object executes in a guest operating system. The statesand behaviors may be provided as dynamic analysis results to BALE, whichmay correlate the results against correlation rules to generate a risklevel or numerical score used in a decision of maliciousness. However,the embodiments in their broader sense are not so limited and may allowfor a subset of the instrumentation logic situated within (or outsideof) VMs and VMMs, yet still configured to provide examination ofinterception points and monitoring of behaviors, including applicationof heuristics, as well as interaction with the BALE as described herein.

The foregoing description has been directed to specific embodiments. Itwill be apparent, however, that other variations and modifications maybe made to the described embodiments, with the attainment of some or allof their advantages. For instance, it is expressly contemplated that thecomponents and/or elements described herein can be implemented assoftware encoded on a tangible (non-transitory) computer-readable medium(e.g., disks, electronic memory, and/or CDs) having program instructionsexecuting on a computer, hardware, firmware, or a combination thereof.Moreover, the embodiments or aspects thereof can be implemented inhardware, firmware, software, or a combination thereof. In the foregoingdescription, for example, in certain situations, terms such as “engine,”“component” and “logic” are representative of hardware, firmware and/orsoftware that is configured to perform one or more functions. Ashardware, engine (or component/logic) may include circuitry having dataprocessing or storage functionality. Examples of such circuitry mayinclude, but is not limited or restricted to a microprocessor, one ormore processor cores, a programmable gate array, a microcontroller, anapplication specific integrated circuit, semiconductor memory, orcombinatorial logic. Accordingly this description is to be taken only byway of example and not to otherwise limit the scope of the embodimentsherein. Therefore, it is the object of the appended claims to cover allsuch variations and modifications as come within the true spirit andscope of the embodiments herein.

What is claimed is:
 1. A system comprising: a microvisor configured tocontrol access to a kernel resource of the system by generating acapability violation in response to an object running in a guestoperating system attempting to access the kernel resource; a type 0virtual machine monitor (VMM 0) disposed over the microvisor andconfigured to expose the kernel resource to an operating system kernelof the system; and a type 1 virtual machine monitor (VMM 1) furtherdisposed over the microvisor and configured to operate under control ofthe microvisor to instrument the object as the object runs in the guestoperating system, wherein the VMM 1 and VMM 0 being configured tocooperate with the microvisor to capture run-time behaviors of theobject as dynamic analysis results in response to the capabilityviolation to detect whether the behaviors are indicative of malware. 2.The system of claim 1 wherein the microvisor comprises a main protectiondomain including one or more execution contexts and capabilitiesdefining permissions for the object to access the kernel resource of thesystem.
 3. The system of claim 2 wherein the VMM 1 is further configuredto create a virtual machine to contain the guest operating system, thevirtual machine bound to a clone of the main protection domainrepresentative of the guest operating system.
 4. The system of claim 3wherein the clone of the main protection domain is created by copyingthe execution contexts and capabilities of the main protection domain,wherein the capabilities of the clone of the main protection domain aremore restricted than the capabilities of the main protection domain withrespect to access to the kernel resource.
 5. The system of claim 1further comprising a behavioral analysis logic engine configured tocorrelate the dynamic analysis results against correlation rules togenerate correlation information pertaining to a level of risk used toarrive at a decision of maliciousness.
 6. The system of claim 5 furthercomprising a classifier configured to use the correlation information torender a decision as to whether the object is malicious, the classifierfurther configured to classify the correlation information, includingthe behaviors and the capability violation, of the object relative toknown malware.
 7. The system of claim 1, wherein the microvisor isconfigured to communicate with the operating system kernel and perform asubset of hypervisor functionality including initiating one or morehyper-calls to implement a virtual machine monitor.
 8. The system ofclaim 1, wherein the virtual machine monitor corresponds to VMM
 1. 9.The system of claim 1, wherein the microvisor executes in a kernel spaceof the system to control access to the kernel resources.
 10. The systemof claim 9 being a virtualization architecture including a trustedcomputing base (TCB) that is configured to provide a trusted malwaredetection environment, the TCB includes at least the microvisor.
 11. Thesystem of claim 10, wherein the microvisor being configured to enforce asecurity policy for the TCB.
 12. The system of claim 11 furthercomprising a behavioral analysis logic engine deployed as part of theTCB, the behavioral analysis logic engine to correlate the dynamicanalysis results against correlation rules to generate correlationinformation pertaining to a level of risk used to arrive at a decisionof maliciousness.
 13. A system comprising: one or more processing units;one or more network interfaces; one or more input/output (I/O) devices;and a memory coupled to the one or more processing units, the memorycomprises a microvisor that, when executed by the one or more processingunits, controls access to a kernel resource, being at least one of acollection of resources including any of the one or more processingunits, the one or more network interfaces and the one or more I/Odevices, by generating a capability violation in response to an objectrunning in a guest operating system attempting to access the kernelresource; a type 0 virtual machine monitor (VMM 0) that, when executedby the one or more processing units, exposes the kernel resource to anoperating system kernel of the system; and a type 1 virtual machinemonitor (VMM 1) that, when executed by the one or more processing units,operates under control of the microvisor to instrument the object as theobject runs in the guest operating system, wherein the VMM 1 and VMM 0being configured to cooperate with the microvisor to capture run-timebehaviors of the object as dynamic analysis results in response to thecapability violation to detect whether the behaviors are indicative ofmalware.
 14. The system of claim 13 wherein the microvisor implementedwithin the memory and executed by the one or more processing unitscomprises a main protection domain including one or more executioncontexts and capabilities defining permissions for the object to accessthe kernel resource of the system.
 15. The system of claim 14 whereinthe VMM 1 of the memory is further configured to create a virtualmachine to contain the guest operating system, the virtual machine boundto a clone of the main protection domain representative of the guestoperating system.
 16. The system of claim 15 wherein the clone of themain protection domain is created by copying the execution contexts andcapabilities of the main protection domain, wherein the capabilities ofthe clone of the main protection domain are more restricted than thecapabilities of the main protection domain with respect to access to thekernel resource.
 17. The system of claim 13, wherein the memory furthercomprises a behavioral analysis logic engine that, when executed by theone or more processing units, correlates the dynamic analysis resultsagainst correlation rules to generate correlation information pertainingto a level of risk used to arrive at a decision of maliciousness. 18.The system of claim 17, wherein the memory further comprises aclassifier that, when executed by the one or more processing units, usesthe correlation information to render a decision as to whether theobject is malicious, the classifier further configured to classify thecorrelation information, including the behaviors and the capabilityviolation, of the object relative to known malware.